Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update messaging for measuring message delay between App and Hub #2499

Merged
merged 19 commits into from
Oct 31, 2024

Conversation

juanscr
Copy link
Contributor

@juanscr juanscr commented Sep 5, 2024

Description

This pull request has two purposes:

  1. Fix the way the message request is timestamped by using a monotonic timer instead of the Date as it could be subject to user clock skew.
  2. Add a mechanism for app developers to access Host to App message delay to analyze how much the message travel time impacts the latency of each function call or initialization.

For the second purpose, with this PR, an app developer can register a function that receives the message delays per function call as soon as a response is received from the host so they can log it or store it in their own telemetry. As app developers do not have information about the internal message IDs, the handler gets passed information about the callback that is resolving so they can approximately pinpoint which call had that message delay.

Note: it was decided to not expose message IDs as it is a really big architectural change in the codebase and the value of exposing them to app developers would be really small in comparison to the change.

Main changes in the PR:

  1. Change the timestamp on all message requests from Date.now() to use performance.now() + performance.timeOrigin.
  2. Add a function to register a handler that will be called each time a response is received from the host with information about the message delay.

Validation

Validation performed:

  1. Ran all the unit tests and passed them successfully.
  2. Execute the build and see that all test apps properly build.
  3. Create a test app with a registered handler and log the values that were being received.

Unit Tests added:

Yes

End-to-end tests added:

No

Additional Requirements

Change file added:

Yes

Data

This is the response message delay for get context:
image
image
image

This is the request message delay for one-way traffic such as change theme: (this one shows more longer timestamps)
image
image
image

This is the request message delay for onw-way traffic fullScreenChanged:
image
image
image

@juanscr juanscr requested a review from a team as a code owner September 5, 2024 03:39
packages/teams-js/src/public/app.ts Outdated Show resolved Hide resolved
packages/teams-js/src/internal/interfaces.ts Show resolved Hide resolved
packages/teams-js/src/internal/communication.ts Outdated Show resolved Hide resolved
@juanscr juanscr force-pushed the juancard/messageDelay branch 2 times, most recently from 61059e3 to fe1cd61 Compare September 11, 2024 00:41
packages/teams-js/src/internal/utils.ts Outdated Show resolved Hide resolved
packages/teams-js/src/internal/telemetry.ts Outdated Show resolved Hide resolved
packages/teams-js/src/internal/telemetry.ts Outdated Show resolved Hide resolved
packages/teams-js/src/internal/telemetry.ts Outdated Show resolved Hide resolved
packages/teams-js/src/internal/messageObjects.ts Outdated Show resolved Hide resolved
packages/teams-js/src/internal/messageObjects.ts Outdated Show resolved Hide resolved
packages/teams-js/test/utils.ts Show resolved Hide resolved
Copy link
Contributor

@ndangudubiyyam ndangudubiyyam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

ndangudubiyyam
ndangudubiyyam previously approved these changes Oct 18, 2024
@juanscr juanscr enabled auto-merge (squash) October 23, 2024 01:57
@maglims
Copy link
Contributor

maglims commented Oct 23, 2024

Just FYI, I think @TrevorJoelHarris has checked in a code refactoring how communication works. You might have to rebase on that and make changes accordingly. @juanscr

@juanscr
Copy link
Contributor Author

juanscr commented Oct 23, 2024

Just FYI, I think @TrevorJoelHarris has checked in a code refactoring how communication works. You might have to rebase on that and make changes accordingly. @juanscr

Yeah, I thought there was going to be an issue with Trevor's changes. But everything is still compliant with this PR, the sync is made tho. Later down the line when the sendMessageToParentAsync function gets removed some changes will need to be done but for now everything keeps working as usual 😄

With this new timestamped messaged, the host can properly compare
and evaluate how much time the request got delayed to an issue on a
busy event loop.
This new handler will allow any application developer to register
a function for analyzing or storing performance metrics related to
latencies due to a message delay sending the response back from the
host to the app.
The old field will be preserved with backwards compatibility
with previous versions that still consume this field.
All the telemetry related code is added to the telemetry module to
avoid cluttering the communication layer with nuances about
telemetry.
ndangudubiyyam
ndangudubiyyam previously approved these changes Oct 28, 2024
maglims
maglims previously approved these changes Oct 29, 2024
@juanscr juanscr dismissed stale reviews from ndangudubiyyam and maglims via 9baa1bf October 29, 2024 23:21
ndangudubiyyam
ndangudubiyyam previously approved these changes Oct 29, 2024
maglims
maglims previously approved these changes Oct 30, 2024
const targetWindow = Communication.parentWindow;
const request = createMessageRequest(apiVersionTag, actionName, args);
HostToAppMessageDelayTelemetry.storeCallbackInformation(request.uuid, {
name: actionName,
calledAt: request.timestamp,
Copy link
Contributor

@sumathin-lang sumathin-lang Oct 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juanscr isnt this "calledAt" supposed to be the monotonicTimestamp

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @sumathin-lang, not necessarily. This information is merely contextual around when the callback happened and isn't used for any calculation. I selected the date instead of the monotonicTimestamp as it should be more proper for a global timestamp as it does not possess issues as not ticking while sleeping and so forth (w3c/hr-time#115 (comment)). I can change it to monotonicTimestamp if you want but it's a minute detail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@juanscr I would suggest using the same "units" for messageDelay and calledAt. Even if the App wants to use this "calledat" to measure some kind of delta, perf.now is a better choice compared to date,now. But i will let the teams-js team make this call

@juanscr juanscr merged commit 6eaa277 into main Oct 31, 2024
28 checks passed
@juanscr juanscr deleted the juancard/messageDelay branch October 31, 2024 20:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants